一种海量数据安全分类分级架构的实现！
导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀，与广泛开发者互启迪共成长。本文作者是腾讯高级开发工程师杨波。
背景
随着《数据安全法》、《个人信息保护法》等相继出台，数据安全上升到国家安全层面和国家战略层面，数据分类分级已经成为了企业数据安全治理的必选题。然而数据分类分级的实现在行业内有很多痛点，主要体现在如下几点：
规则制定复杂：数据进行分类有多种维度，不同维度各有价值。在不同行业及领域，甚至具体到每个企业和部门，针对不同级别数据也各有定义。维度、级别的不清晰会导致后续基于分类分级的很多合规管控存在问题。
协调沟通成本高：企业规模不断庞大，组织架构也随之变得复杂臃肿。数据的扫描上报关联到多个部门和事业群，甚至子公司。这涉及到多人之间的协调沟通，还需考虑网络隔离，访问权限和审批等诸多问题。
数据容量大：互联网时代到来，企业信息化建设一直高速发展中，业务系统也越来越复杂。随之产生的海量数据，给企业带来巨大的价值。相应一旦海量数据泄漏，也会给企业造成严重的后果。如何实时，高效，全面覆盖海量数据分类分级，这对技术架构是一种考验。
存储组件多：互联网尤其是云计算时代，企业为了应对大流量高并发业务场景，诞生关系型，非关系型，对象存储等多种存储组件。这既有开源实现，也有企业内部自研。不同的实现，有着不同的传输协议和数据结构。要覆盖多种存储组件数据分类分级，需要大量的工作量。
然而查阅公司内外很多资料，往往只着重讲解数据分类分级概念与标准。目前并未有可借鉴，可落地的分类分级技术实现参考。因此本文重点不在于讨论数据分类分级的标准制定，而是从技术层面来讲述一种通用能力抽象封装，海量数据识别，跨部门和平台数据接入的分类分级架构实现。将数据分类分级技术进行赋能，避免重复造轮子。并以此为基础来从实际角度满足数据安全合规工作的落地和推展。
注：数据分类分级介绍参考数据安全治理：数据分类分级指南。
数据安全业务流程
（一）业务层面
从业务层面看，以数据分类分级作为数据安全的基石，来对数据进行安全管控，比如数据加密，数据脱敏，数据水印，权限管理，安全审计等。可见数据分类分级对数据安全的重要性。
（二）技术层面
从技术层面看，将数据扫描上报，通过数据识别引擎进行识别。然而在实际落地过程中，却发现很多问题。比如存储组件种类多，上报数据流量大，以及时效性，准确率，覆盖率等等问题。
整体架构
通过不断对数据分类分级业务分析，设计如上数据分类分级架构。架构核心由五大块组成：
多种存储组件数据扫描上报工具。
数据识别服务集群，统一接收上报数据，并进行数据识别。
识别规则引擎，统一维护识别规则的管理，在线热更新等功能。
数据中台，依托分类分级结果，进行数据安全管控。
依托公司的基础框架能力，保障引擎服务的高可用，比如监控，告警，日志，弹性扩缩容等。
其中重点要处理前三点。
海量数据实时识别
企业规模不断庞大，海量用户，必然产生海量数据。如何满足高性能，时效性同时，又能达到高正确率和覆盖率要求，对于系统架构是一个巨大考验。
（一）数据存储
PCG目前覆盖近二十种存储组件类型和平台，三千万张表，以mdb，cdb，tredis，天穹为例：
存储选型
从表格可见，仅mdb已超过五百万张MySQL表，而cdb甚至超过一千万张MySQL表。而一张MySQL表即对应要保存一条分类分级识别结果。MySQL单表数据建议在五百万左右，超过这个数据量建议通过分库或分表处理，这在电商项目一些场景是可行，比如交易订单数据。但这也会带来经典的分布式事务等问题。
因此需要选择一种满足大容量，高并发，高可用和事务acid的数据库。
大数据hadoop
hadoop作为经典大数据存储架构，可存储pb级别以上数据，但时效性不高，通常用作T+1离线任务olap场景。且hadoop对事务acid支持有限，无法满oltp场景。
tidb
tidb是一款分布式海量容量云原生newsql。tidb底层使用raft算法，实现数据分布式存储和保证数据一致性。同时兼容MySQL协议，支持事务。因此tidb满足要求，然而公司目前没有专门团队维护tidb。
云原生tdsql-c
tdsql-c是TEG自研的一款的数据库。tdsql-c对MySQL架构做了改进，将计算和存储分离，从而实现存储和计算资源的快速扩容。因此tdsql-c支持MySQL协议和事务，同时具备高性能等特性。且公司目前有专门团队维护tdsql-c。
存储对比
从表格可见tidb和tdsql-c满足需求，但tdsql-c有公司内部专人维护。因此选择tdsql-c来存储数据分类分级识别结果。
（二）数据接入
服务端需要对接多种存储组件平台的数据上报，不用平台对资源，性能，时效性有不同要求。因此实现http，trpc，kafka多种接入方式，以满足不同场景。
kafka传输大数据
kafka可以实现消费端失败重试，且可以对流量进行削峰，推荐使用kafka进行数据上报。
为了保证识别结果正确，对关系型数据库单表取200条数据上传。大数据存在一些宽表或者大字段，导致上传的数据超过1M，这超过了kafka默认配置。除了限制上传数据包大小以外，也需要对kafka配置进行优化。
kafka producer
max.request.size=1048576 （1M）
batch.size=262144 （0.25M）
linger.ms=0
request.timeout.ms=30000
由于消息数据包比较大，因此不希望消息常驻producer内存，造成producer内存压力，因此让消息尽可能快速发送到broker端。
kafka consumer
fetch.max.bytes=1048576（1M）
fetch.max.wait.ms=1000
max.partition.fetch.bytes=262144（0.25M）
max.poll.records=5
topic partion>=20
retention.ms=2
优化效果
数据识别
在解决数据上报，数据存储，数据接入以后，便是数据识别。这是整个数据分类分级架构最核心也是最复杂部分。对数据识别过程主要分为数据映射，规则管理，权重计算，数据校验四大块。
数据映射
服务端对单表取200条数据进行识别，按每张表20个字段，每个字段需进行20种正则识别。每天假设跑1千万张表，一共大概要跑8千亿次正则计算。如此巨大的计算量，在流量冲击下，立马将服务端的cpu飙升到100%，从而导致服务不可用！！！
相对于io密集型，cpu密集型无法简单使用常见的缓存，异步等方式去减轻服务端压力。因此需要考虑点如下：
通过云上k8s弹性扩缩容，将流量分散到多个容器节点，降低单节点负载压力。
单节点利用多核并行，将计算压力分担到多个cpu核处理器上。并且使用信号量限流，避免cpu一直处于100%。
正则表达式优化。藏在正则表达式里的陷阱，竟让CPU飙升到100%！
多核并行
多核并行借鉴MapReduce编程模型，本质是一种“分而治之”的思想。
优化效果
规则管理
数据的分类分级，需更精细化的规则管理，才能对后续数据安全做到更合理的管控。规则包括不限于正则，nlp，机器学习，算法，全文匹配，模糊匹配，黑名单等。对应每种具体分类分级定义，又包括多个规则的组合使用。通过实际的运营和梳理以后，目前有近四百种分类分级定义和八百种识别规则。
因此需考虑合理的方式，将规则管理和识别逻辑解耦，以便后续的维护和升级。同时需考虑规则热更新和关闭，做到对线上服务无感知。
权重计算
数据分类分级，在不同行业和业务有不同的维度和定义。且源数据由于开发和运维人员定义不清晰，导致最终识别结果存在模糊的边界。在实际运营过程中，常会因为识别结果不准确，被业务方反馈。
假设有字段叫xid，有可能是qqid，也可能是wechatid，而qdid和wechatid对应不同的分类分级，这会影响后续的合规流程。在实际场景，xid有可能同时被qqid和wechatid识别规则命中，那么该取哪个呢？
因此引入权重的概念，权重不在于将识别结果做简单的0和1取舍，而是通过多个组合规则识别后，计算出一个权重值，并对多个识别结果的权重值进行排序，取权重最大的识别结果作为当前字段的分类分级。
数据校验
数据安全合规管控，最重要一项是数据加密。为了方便运营后续进行合规追溯，需要在服务端对当前上报数据是否加密进行校验，并将校验结果保存下来。
数据是否加密需综合判断库表状态等信息，其中包括数据是否加密，表是否删除，库是否删除，实例是否下线等。状态的转换，通过以下决策树表示：
跨部门和平台接入
在重点解决数据上报和数据识别等难点以后，数据分类分级框架已可以满足大部分业务场景。因此也希望框架能服务更多的部门需求，减少大量繁琐重复的工作量。
由于数据分类分级结果属于敏感数据，对于跨部门和平台接入，需考虑将数据根据不同部门和平台进行物理隔离存储。
总结
架构没有好坏之分，只有合适一说。本文所讲述是基于个人在落地过程遇到问题的经验总结。因此反复斟酌，认真梳理写下本文，也是对本人工作的一个阶段总结。同时也希望框架能得到更多人认可，并达到数据分类分级能力复用，为公司数据安全合规工作尽到一点小小贡献。
作者简介
杨波
腾讯云开发者社区【技思广益·腾讯技术人原创集】作者
腾讯高级开发工程师，熟悉分布式，微服务，RPC等领域知识。目前负责PCG数据中台，数据安全治理等相关研发工作，有丰富后端的开发经验。推荐阅读
👇点击「阅读原文」，注册成为社区创作者，认识大咖，打造你的技术影响力！